查看原文
其他

回顾·音乐垂域的自然语言理解

秦斌 DataFunTalk 2019-06-05


DataFun社区

大数据、算法的交流学习平台 圈内人都在关注

 

本文根据小米智能云秦斌老师在DataFunTalk人工智能技术沙龙“自然语言处理技术应用实践”中分享的《音乐垂域的自然语言理解》编辑整理而成,在未改变原意的基础上稍做删减。

(秦斌老师在活动现场)

今天分享的内容有项目研究背景、实现了那些功能,在做音乐领域时有哪些独有的问题与挑战,还有就是“小爱”项目具体的实现。

上图是整个小爱语音交互平台的后台服务架构,小米大脑定位的是一个平台,能够处理各种数据。在最外部给各种厂商封装了SDK接口,目的使厂商能够很快的接入,降低你接入成本,如果你要操作小米相关智能设备就要MOIT授权验证。后续会有小米语音服务ASR,语音识别都在客户端,由于平台特性,在云端接入ASR厂商,如微软、百度、科大讯飞、猎狐星空等,部署于云端便于控制和优化,可以额外做一些文本选择等功能。语音转化为文本就会进入NLP模块,在NLP中控部分会做一些个人训练计划、公共训练计划、还有一些query概率,然后将其发布到精品垂域,采用分而治愈的思想,每一个垂域将这个领域的语料、知识、常见说法给建立起来,由中控选择最终的垂域。最外部有一个设备开放平台oivs,方便各种硬件设备厂商接入。后续还有一个技能开放平台,第三方技能开发者能够在平台上很简单的实现一个技能,如打开成语接龙或闲聊,将query转给第三方技能。周边就是机器存储、机器学习平台等资源平台。

接下来介绍下,一个垂域要做那些事情。如飞机票垂域,要理解用户的意图,是要购票还是退票,音乐就是你要找歌手、听歌、还是找一个推荐;在意图理解后抽取Slot(一个个的字段),如时间、出发地、目的地。整体就是将一个纯文本机构化,将相关信息抽取出来,这是做语义理解经常要做的事情。

接下来介绍下音乐领域实现了那些功能,第一个就是用户的个性化推荐,如随便放首歌、歌单等。再往后就是一个搜索意图,比如我要听周杰伦的歌,周杰伦的简单爱,抽取“歌手/歌名/专辑/标签”四类字段(slot)信息。字段消歧,如“三生三世十里挑花的歌”,其实这是一个专辑,同时也有首歌叫三生三世十里桃花,通过用户原始信息知道应该是专辑而不是歌名。ASR不可能完全准确还有用户发音问题,因此需要纠错,纠错太多召回存在问题,一言不合就放歌,把握不好就会觉得你太笨,对“歌手/歌名/专辑/标签”字段的”同音/补全/乱序”纠错。如歌手同名问题,歌词错误,歌名与歌手对应错误等。

还有一些音乐特色功能:(1)音乐意图的上下文继承,对字段信息进行信息补全或指代消解。如我想听刘德华的歌,完了又说要播放他的笨小孩,那就是“刘德华的笨小孩”;(2)用户情感分析。如“我想听岁月神偷不要听金玟岐的”,就是对Artist的一个否定;(3)指定播放顺序;(4)根据歌词内容识别歌曲,如“海草海草”识别到是“海草舞”;(5)收听历史歌曲,需要提出时间信息。

上面介绍音乐要实现的功能,接下来介绍遇到的挑战。首先(1)实体名太过复杂,形式多样,没有固定的组成规则;知识库数量巨大,如QQ音乐是千万级,网易云音乐数百万,阿里系也有数百万。由于歌数量巨大,很多都垄断,要识别这些歌曲需要建立知识库,但是原始数据存在很大的噪音,缺少字段信息,歌名不规范。需要将海量数据爬取下来,判重。(2)用户说法很乱,不符合自然语言,比较简单,没有固定形式,半结构化文本。(3)实体名纠错。由于实体名自身的复杂性和多义性,存在着同音纠错,方言纠错,乱序纠错等多种纠错情况。

知识库很多,实体名很复杂,单纯用词表不能很好地解决这个问题,采用了知识库加搜索的方案。搜索能很容易解决数百万知识库,不存在性能问题,搜素排序算法技术比较成熟,搜索保留了歌的物理信息,如“王菲红豆”就能知道是红豆这首歌,但是如“韩红红豆”就不是歌了。歌来源有爬取的也有合作的,进入知识库后会有一个文本搜素,抽取feature,利用learn to rank排序,通过query确定用户想听那首歌,确定歌名,抽取slot,利用GBDT模型打分。还有User feedback,language model,domain frequency(利用用户行为反馈,改善向量效果)。后面就是个性化的搜索和推荐,如用户的性别、行为,歌一放出来就切换,还有音乐的热度、风格、发行时间等。大致流程会对query做一些前置理解,后续从知识库中找到与之相关的歌,抽取slot,然后进行语义消歧。然后打分,然后利用语言模型判断是否符合常用规则。

数据是核心,资源主要来自资源方、垂直网站还有人工运营平台。获取数据后对数据进行归一化,做相应的映射,打一些标签。还要排重,一家网站一首歌也会存在很多版本,但是我们只需要原始数据忽略版本。后续就进行DB、内容评审、构建索引等,清洗数据会花费大量时间。

音乐NLU整体架构,分为意图抽取、知识库搜索排序、字段抽取、路径选择及打分、线上数据反馈。意图抽取会对query进行预分析,数据预处理,然后中文分词还有推荐意图分类器,还有文法规则,最后找到一些主干query供后续搜索,先理解query语义上的可能的一些倾向性的方向判断,找到主干query供第二部使用。

接下来介绍一下推荐意图分类器,在获取query时,增加了一个二分类判断,判断是否是推荐意图,目的是简化搜索,节省时间,同时为策略判断给出一些特例。具体做法是中文分词后抽取n-gram特征,如单词特征、二元特征、三元特征,最后利用逻辑回归。后续会使用Woed2vec,因为word2vec 能够捕捉更多语法和语义特征。

接下来就是文法规则匹配,自定义了一套文法规则,支持变量的定义、文法的组合、文法替代,目的是对query语义做倾向性判断。还有影视类、标签类的词典,标签文法对标签进行了强分类(强标签、弱标签)。

第二部分局势知识库搜索排序,基于Linden做的搜索。Linden是基于开源的Lucene包,Linden就是将其服务化,集群管理,加入类似SQL语言,便于集群查询。单词搜索主要针对用户说法很乱,如果进行切词可能无法召回,但是出现的问题是召回太多。最后会对初排后结果learn to rank,进行重排。

知识库中有数百万的数据,每周都需要评测更新一半的索引,上线有严格的流程,线上的策略改动、数据改动都要经过评测才能上线,还有人工审核top query。知识库索引设计支持歌手、歌名、歌手别名、专辑和影视类字段的综合搜索,支持单字和拼音两类搜索方式。知识库搜索初排也会支持降权,在搜索时就进行降权。

在初排后进入中间层会利用排序算法进行二次排序,如从top80里面选择一个最相似的文档。正负样本比例失衡,适用于Learn to rank算法,最后选用LamdaMart,采用决策树模型会学习到很多特征组合。模型特征有字段匹配类别、相似度,字段匹配长度,字段纠错类别,文档热度等50多个相关特征。

通过相关特征选择一首歌后,进行字段抽取。涉及资源字段的抽取和纠错,标签字段PK资源字段,如判断青春是歌手还是歌名,上下文字段继承,否定意图等。字段抽取是基于纯规则,有些热门歌曲唱错时也会将其选择出来,如一个歌手没唱过这首歌,但是如果是热门歌曲也会选择出来。

打分是基于意图分类和规则打分,还有基于语言路径的用户选择。由于语言的歧义性可能会选择多条路径,典型二分类问题,缺少其他domain打分信息结合少量必要规则,替代原有规则系统。最终选定GBDT算法,利用各种特征,如职业特征,郭德纲、岳云鹏都唱过歌,但是职业是相声演员,单说歌手就会将其推电台。还有一个优势就是APP搜索日志,小米音乐大都是key-words搜索,如果在日志中找到也是属于音乐特征。

文本搜索有用户点击信息,但是语音很难找用户行为特征信息,尤其命令型语音,得不到用户反馈。但音乐可以获取用户听没听这首歌,听了多久。利用的是全领域知识反馈模型,利用DFTF思想,如“大王叫我来巡山”在音乐领域用的很多,当出现大王,就很容易召回。另外还有完成率,就是用户完成行为反馈模型,用户听了多少歌,首条完成率,即第一首歌听完的概率,还有30秒切歌率等指标。

项目目前存在的问题,音乐过召回严重,音乐slot抽取准确性仍需提高,知识库的准确性和完整性存在不足, 聊音乐,想做电台式音乐,这样显得智能,一首歌结束会引出小爱的评价,引出下一首歌。端到端,利用click model训练端到端模型,知道一些query在历史上选为音乐意图,当一个新query来后与历史query比对,如果词向量相近,直接返回结果,简化操作。

——END

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存